Whereas conventional 2G mobile networks, such as those conforming to the Global System for Mobile Communications (GSM) standards, have provided circuit-switched voice and data services to user's mobile stations (MSs), there is great momentum in the mobile telecommunications industry to deploy packet-switched mobile networks. Packet-switched mobile networks have significant advantages in terms of network and radio resource efficiency and also enable the provision of more advanced user services. With the convergence of fixed and mobile telecommunications networks, the Internet Protocol (IP), widespread in fixed networks, is the natural choice as the packet routing mechanism for mobile packet networks. Currently IP version 4 (IPv4) is in widespread use in the fixed network domain. However, it is expected gradually to migrate to IP version 6 (IPv6) which offers well-recognised benefits over IPv4, notably in terms of greatly increased address space, more efficient routing, greater scalability, improved security, Quality of Service (QoS) integration, support for multicasting and other features.
Particular examples of mobile packet-switched services currently being deployed include the General Packet Radio Service (GPRS) as implemented in both 2G GSM networks and in 3G Universal Mobile Telecommunications System (UMTS) networks (hereinafter referred to as GPRS networks). It is also expected that non-GPRS wireless access technologies, such as wireless Local Area Network (wLAN), will provide a flexible and cost-effective complement to GPRS for local broadband service access in some areas such as hotspots (conference centres, airports, exhibition centres, etc). Consequently mobile network operators will want to support roaming of mobile stations between GPRS and non-GPRS networks or subnetworks.
While GPRS networks, having been designed from the start as mobile networks, have built-in mobility management (for MSs within the GPRS network) and roaming functionality (for MSs roaming between GPRS networks), work has also taken place in the Internet Engineering Task Force (IETF) to support mobility of IP user terminals in general. To this end, the IETF have developed the Mobile IP (MIP) protocols. MIP is designed to support mobility when mobile stations (or mobile nodes (MNs) in MIP terminology) move between IP networks with different subnet prefixes (macro-mobility). For example, MIP may be used to support mobility between a GPRS network and a non-GPRS network such as a wLAN network. Mobile IP is not expected to be used for mobility management within a network or subnetwork (micro-mobility) which is typically managed by access technology specific layer 2 mechanisms such as WCDMA softer/soft handover.
There are two versions of MIP to correspond to the two versions of IP. MIP version 4 (MIPv4) is designed to provide IP address mobility for IP version 4 (IPv4) addresses, whereas the newer MIP version 6 (MIPv6) MIP is designed to provide IP address mobility for IP version 6 (IPv6) addresses. MIPv4 is described in the IETF Request For Comment (RFC) 2002 available at the IETF website. Internet draft MIPv6 is described in the IETF Internet draft “Mobility Support in IPv6” available at the IETF website.
MIPv4 mobility management is illustrated in FIG. 1. A MN 40 is allocated a home IP address (HAddr) in its Home Network (HN) 42. Routing procedures in the HN ensure that wherever the MN is within the HN, an IP packet sent from a Correspondent Node (CN) 46 will reach the MN. However, when the MN roams to a foreign network (FN) 44, IP packets addressed to its HAddr will need to be routed to its new location in the FN. In MIPv4, a router 48 in the HN known as the Home Agent (HA) is used to act as a packet forwarding service on behalf of the MN when it is away from home. In a first working mode of MIPv4 (known as FA-CoA mode), when arriving in the FN, the MN is allocated a Care of Address (CoA) by a router 50 in the FN known as the Foreign Agent (FA). Due to perceived limitations of IPv4 address space, it is envisaged that more than one MN may share the same CoA. After allocation of the CoA, the FA 50 sends a binding update to the HA to register the CoA. Thereafter, when the CN sends a packet to the HAddr of the MN in its HN (case 1), the packet is intercepted by the HA and tunnelled to the FA in the FN via tunnel 52 on the basis of the CoA.
Tunnelling involves encapsulating a first data packet (with a header and a payload) as the payload of a second data packet having a new header indicating, as its source and destination addresses, the start and end points of the tunnel, and transferring the second data packet as normal to the tunnel endpoint where it is decapsulated to obtain the first packet. After decapsulation, the tunnel end point, the FA, routes the original packet to the MN using routing procedures in the FN. In MIP, tunnelling involves IP in IP encapsulation using the IETF Request For Comment (RFC) 2003. Thus in MIPv4, an IPv4 packet is tunnelled by encapsulating it within another IPv4 packet.
As an optional procedure in MIPv4, the MN may then send a binding update to the CN to register its CoA. Thereafter, the CN may address packets directly to the MN at its current CoA, rather than indirectly via its HAddr (case 2), and these packets are received by the FA in the FN and routed to the MN using routing procedures in the FN. This is known as route optimisation since it avoids potentially inefficient triangular routing via the HA which in general will not be on an efficient routing path between the CN and the FA.
In a second optional working mode of MIPv4 (known as CoCoA mode) there is no sharing of CoAs by MNs away from their home network and no FA is used. The MN is allocated a unique CoA, known as a co-located CoA (CoCoA), using standard dynamic IP address allocation procedures—eg using Dynamic Host Control Protocol (DHCP). In this working mode, the MN must itself send a binding update to its HA to register its newly allocated CoCoA. Thereafter, packets sent by a CN and addressed to the MN at its HAddr are tunnelled from the HA directly to the MN. As with FA-CoA mode, as an optional procedure in CoCoA mode, the MN may also send a binding update to a CN to register its CoCoA. Thereafter, packets may be sent by the CN directly to the MN at its CoCoA.
MIPv6 mobility management is illustrated in FIG. 2. Two notable differences of MIPv6 over MIPv4 are as follows. Firstly, due to the greatly increased address space in IPv6, CoAs allocated to a MN in a FN are never shared (ie they correspond to the optional CoCoA in MIPv4). Secondly, as a result, there is no need to deploy a FA in the FN. Referring to FIG. 2, with MIPv6, when a MN 40 moves from its HN 42 to a FN 44, it is allocated a unique CoA and sends a binding update to its HA 48 in its HN to register the CoA. Packets from a CN 46 addressed to the HAddr are intercepted by the HA 48 (case 1) and tunnelled to the CoA via tunnel 54. This tunnelling may be achieved using IPv6 Generic Packet Tunnelling Mechanism described in IETF RFC 2473. However, in MIPv6, route optimisation is not an option but a fundamental part of the protocol and, in general, the MN should send a binding update to the CN so that it may address packets directly to the MN at its CoA (case 2). When an MN receives a packet tunnelled from a CN via the MN's HA, it may take this as an indication that the CN has no binding for the MN and initiate a CN binding update. Note that in MIPv6 the CN binding update must use the new CoA of the MN as the source address in the IPv6 header (see Clause 11.6.2 of the MIPv6 IETF Internet draft).
The 3rd Generation Partnership Project (3GPP) responsible for the GPRS standards has recognised that MIP may need to be supported in GPRS networks. Technical Specification 23.060 Clause 5.7 states that “To support the optional Mobile IP services, see 3G TS 23.121, efficiently in the packet domain, Foreign Agent (FA) functionality needs to be provided in the GGSN. The interface between the GGSN and FA, including the mapping between the care of IP address and the GTP tunnel in the PLMN is assumed not to be standardized as the GGSN and FA are considered to be one integrated node.” Furthermore, 3G TS 23.121 (available from the 3GPP website) states that “ . . . it is important to offer Mobile IP also to UMTS and GPRS users to allow them to roam to and from other access technologies while keeping ongoing data sessions, e.g. TCP or UDP” and that “as IP addresses in IPv4 are scarce, it has to be assumed that Mobile IPv4 preferably will be used with the Foreign Agent (FA) care-of addresses. Compared to using co-located care-of addresses, FA care-of addresses does not only conserve IP addresses, it is also more efficient over the radio interface.”
However, there may be circumstances in which the above assumptions are false. Firstly, a GPRS network operator may want to use CoCoAs in MIPv4 instead of FA CoAs. For instance, IPv4 addresses may not be scarce within a particular GPRS network and CoCoAs may be preferred to improve scalability and routing efficiency. Secondly, there may be circumstances in which the GPRS network operator would not want to integrate FA functionality in the Gateway GPRS Support Node (GGSN) which is the gateway connecting the GPRS network to external packet-switched networks. For instance, the GGSN may be heavily loaded and separating the GGSN and FA functionality would improve load balancing. Furthermore, it may be considered beneficial to locate the FA in nodes which are closer to the edges of the GPRS network, such as access nodes, for improved scalability. Thirdly, the 3GPP has itself recently mandated that IPv6 must be supported in UMTS R5 IP Multimedia System (IMS) and IP radio access networks in general. Thus, it is clear that GPRS networks will need to support MIPv6 as well as MIPv4 in future and, as described above, MIPv6 has no FA and uses CoAs which are unique to the MN (ie always “co-located”).
The present inventors have realised that problems arise in GPRS networks implemented according to the present service descriptions (Release 1999) in each of the three circumstances listed above. One particular feature of GPRS networks, which conform to Release 1999 and Post Release 1999 (e.g. R4, R5) of the GPRS Service Description, is support for what are known as packet data protocol (PDP) contexts. Specifying different PDP contexts are useful for a variety of reasons. In particular, PDP contexts allow differing QoS levels and other parameters to be specified for traffic to and from a single PDP address of a MS. This allows efficient transfer of a variety of data traffic, such as non real-time traffic (eg intermittent and bursty data transfers, occasional transfers of large volumes of data) and real-time traffic (eg voice, video). For example, a MS in a GPRS network, having a PDP address, such as an IPv4 or IPv6 address, may communicate with a plurality of other telecommunications devices in external packet-switched networks using different PDP contexts with differing QoS parameters for each one. It is generally the duty of the MS to create and modify PDP contexts as required.
Incoming data packets from an external network for downlink to a MS are received in the GPRS network by the GGSN. If the PDP address of the MS has multiple PDP contexts established, it is essential that the GGSN be able to determine the appropriate PDP context for each packet, so that it may be transferred appropriately to the MS. This is achieved by using Traffic Flow Templates (TFTs) associated with PDP contexts. The TFTs may contain packet filtering information used by the GGSN to determine the appropriate PDP context for downlink data packets. According to current 3GPP standards, one specified item of information for use in packet filtering is the source address of the incoming data packet—eg the IP address of the source node as specified in the IP packet header. When an incoming data packet arrives at the GGSN, its source address is checked against existing TFTs associated with the PDP address of the MS. If a match is found, the packet is transferred to the MS at its PDP address according to the appropriate PDP context. If, however, no match is found, the packet may be dropped by the GGSN. Here is where the problem arises.
Let us suppose that the MS in the GPRS network is provided macro-mobility through MIPv6 and has just moved to the GPRS network which is a FN—ie it has a HA and a HAddr in a HN (which may or may not be a GPRS network) and has moved to the GPRS network where it has been allocated a CoA. Let us now call the MS a MN and the telecommunications device in the external network a CN for consistency with MIP terminology. After moving to the GPRS network, the MN will send a binding update to its HA in its HN reporting its new CoA. It will normally also send a binding update of its new CoA to the CN. However, even if it does, the CN may still send data packets to the MN at its HAddr for various reasons. Such data packets will be intercepted by the MN's HA and tunnelled to the MN using IPv6 tunnelling (RFC 2473). According to RFC 2473, “At encapsulation, the source field of the tunnel IPv6 header is filled with the IPv6 address of the tunnel entry-point node”—ie the IPv6 address of the HA. Thus, a tunnelled data packet arriving at the GGSN in the GPRS network will not have the IP address of the CN as its source address, but the IP address of the HA (nb this is not the HAddr of the MN). This address cannot be recognised by the GGSN using a TFT identifying the source address of the CN and the data packet may be dropped.
Conceptually, the problem may be thought of as the MIP tunnel extending past the GGSN and “hiding” the CN source address from the GGSN. This will also be the case in MIPv4 if the FA is not integrated into the GGSN but is located further towards the edges of the network, or where CoCoAs are used, since, in both cases, the tunnel end-point will again extend beyond the GGSN. Also note that this problem applies in the general case where the MN moves to the GPRS network as a FN, even if there is no communication session established with a particular CN. It may be expected that a possible future CN will want to send data packets to the MN via its HAddr for various reasons, and that this will be tunnelled via the HA. Hence the problem arises in general.
The present invention provides a solution to the above problem.